<html>
  <head>
    <title>ConArtist!</title>
    <link rel="stylesheet" type="text/css" href="css/style.css" />
  </head>
  <body>
    <div id="document">
      <div id="header">
        <h1>Welcome to ConArtist!</h1>
        <ul>
          <li><a href="overview.html">Overview</a></li>
          <li>Design Documentation</li>
          <li><a href="started.html">Getting Started</a></li>
          <li><a href="api/">API Documentation</a></li>
        </ul>
      </div>
      <div id="content">
<h2>50,000' Overview</h2>
<p>ConArtist is a project of two parts. The first part is a web publishing system that aims to</p>
<ul>
  <li>eliminate the need to store generated content</li>
  <li>allow easy integration with Subversion</li>
</ul>
<p>The second part of ConArtist is an application based on the publishing system that will allow conferences to be planned and managed.</p>
<h2>Current Status</h2>
<p>Presently some work has taken place on developing the publishing system but very little beyond some initial design thoughts has been done for the conference management system.</p>
<h2>Documentation Available</h2>
<p>This site aims to bring all the documentation for the project into one central place.</p>
<ul>
  <li>Overview</li>
  <li>Design Documentation</li>
  <li>Getting Started</li>
  <li><a href="api/">API Documentation</a> - generated by doxygen from the header files needed for the ConArtist shared library.</li>
</ul>


<p>ConArist is an effort to create an open source conference management system. It grew from an initial conept to look at building a "data infrastructure" around conferences in an effort to allow easier management of the data and production of websites. The initial target was ApacheCon but looking around there are very few open source projects that cater for conferences so the idea grew to produce a more generic conference management tool.</p>
<p>While looking at starting the project there seemed to be a lack of a suitable "hosting environment" for the desired objectives, at least in a language that we wanted to work with. after spending some time thinking about this ConArtist started creating it's own framework that will act as the hosting environment, but should also be usable outside of the project.</p>
<h2>Producing Output from Source Data: A Web Publishing Framework</h2>
<p>The hosting framework for ConArtist will be the first piece created. It's a totally new codebase written in 'C' and meant to interact directly with the Apache httpd server and command line apps. An overview follows.</p> 
<p>ConArtist is aimed at websites that need to generate output from one or more data sources in a variety of different ways. It aims to allow a simple configuration file to be used to control how the data is converted into the desired output format, in a number of different ways.</p>
<div class="example">
<h3>Example</h3>
<p>A website stores the data for the various HTML files it serves as XML files. Some of these XML files are directly converted into HTML using an XSLT stylesheet. Some are concerted into another form of XML before being converted into HTML files. There are also files served by the website that are created by aggregating a number of XML files and then converted into HTML, RSS or ATOM using XSLT stylesheets.</p>
<p>Currently the site is generated using a scripts to perform the conversions and the HTML, RSS and ATOM files are served directly.</p>
<p>ConArtist approaches the problem in a different manner. Instead of simply performing the conversions and then storing the HTML files it simply stores the raw data files and converts them into the required files when requested. How it does this is configured by the user via a configuration file.</p>
<p>The configuration file defines</p>
<ul>
  <li>where the data is found (Stores in ConArtist)</li>
  <li>processes to create output from the data (Pipelines in ConArtist)</li>
  <li>mappings between the requested output and data</li>
</ul>
<p>In the above example all the data resides in a single Subversion repository, so only one Store is configured. The Subversion respository is checked out and made available locally to keep network lag to a minimum.</p>
<p>The processes that are involved are identified and configured as follows</p>
<ol>
  <li>XML + XSLT = HTML</li>
  <li>XML + XSLT = XML + XSLT = HTML</li>
  <li>XML + XSLT = RSS</li>
  <li>XML + XSLT = ATOM</li>
</ol>
<p>Each of these processes is created as a Pipeline that can be called as required.</p>
<p>Finally the URL's that may be requested are added to the configuration file with details of which files and pipelines generate the required output.</p>
<p class="example">e.g. URLs '/(filename).html' are generated using pipeline #1 and data file '/website/(filename).xml' from the Subversion repository.</p>
</div>
<p>In this way the generated output is only created as needed and by altering the configuration file the entire site can be easily adjusted. The use of a cache of the generated output will reduce the server load by not requiring every request to require generation. Implementing the cache internally means that it can be updated whenever data is altered removing the risk of serving out of data content.</p>
<p>The generation of content is controlled by configuration of pipelines and URI mapping within each generator.</p>
<p>A pipeline is simply a series of functions that are performed on a file. Each function is termed a "pipe" and is essentially self contained. Output from one pipe is used as the input to the next. When the pipeline is run every pipe is processed in turn as long as they are succesful. Pipes are provided by loadable modules and created </p>
<p class="example">e.g. In order to transform XML data into HTML using an XSLT stylesheet an "xslt" pipe is added to the pipeline.</p>
<p class="example">e.g. Content is created using a templating system that requires a custom data format. 2 pipes are added to the pipeline, the first creates the data for the template and the second generates the output via the template.</p>
<p>Each pipe is created with an XML configuration block, allowing every pipe type to have a different set of configuration directives.</p>
<p>The hardest part of the configuration is determining the content to generate for a particular URI. This is done via a series of URI Map configuration items. Each map section details how to generate content for either one particular URI or a number of URI's via a wildcard file pattern.</p>
<p class="example">e.g. A configuration block with a file pattern of /index.html determines how to generate only /index.html, but the file pattern /*.html will match any URI with an html extension in the root directory.</p>
<p>Each map configuration section details which file should be used for input and which pipeline should be run in order to convert the data.</p>
<p>In addition to the maps configured for each generator, a number of default mappings are available. These simply allow for direct URI to file mappings.</p>
<p class="example">e.g. Instead of needing to add a map configuration for /images/*.jpg the default maps will work if the store contains a filepath /images/*.jpg.</p>
<p>In addition to the generation of content map configuration sections can also be used to establish dependancies between content, whether generated or not.</p>
<p class="example">e.g. Content is generated using XML files with a series of XSLT stylesheets, but they rely on a generated XML file containing the navigation links required. This is added as a dependancy in the map configuration sections and when requested the map configuration section that details how the file is generated is used to create the file prior to generating any files that rely on it.</p>
<h2>Conference Organisation</h2>
<p>The ConArtist project started with the intent of creating an open source conference/meeting management tool. Layered on top of the framework described above, it will attempt to provide an open, flexible management tool that conference planners can easily use.</p>
<p>There are a very large number of areas that need to be looked at, including</p>
<ul>
  <li>dates and venues</li>
  <li>content (presentations, tutorials, meetings, keynotes, etc)</li>
  <li>timetable</li>
  <li>people delivering content (speakers, etc)</li>
  <li>attendees</li>
  <li>sponsors</li>
</ul>
<p>The system created should also be able to automate a lot of tasks and provide a large amount of flexibility in how it integrates with other services.</p>
<h2>Project Aims</h2>
<p>As always when starting a project the initial set of aims occupy the entire spectrum from "easy" to "nigh on impossible" and while it would be nice to achieve everything on the following list, the project is realistic enough to know that not all of these will be achieved.</p>
<ul>
  <li>Open Source (using a version of the <a href="http://www.apache.org/licenses/LICENSE-2.0">AL 2.0</a>)</li>
  <li>Open Data Standards</li>
  <li>Easily configurable</li>
  <li>Relatively easy to deploy</li>
  <li>As much reuse of information as possible</li>
  <li>Scheduling facilities</li>
  <li>Dynamic website generation</li>
  <li>Ability to use information from multiple sources</li>
  <li>Extensible architecture</li>
</ul>
      </div>
      <div id="footer">
        <p>&copy; 2007</p>
      </div>
    </div>
  </body>
</html>
